Communication Routing Apparatus 
Field of the Invention 

The present invention relates to a communication routing apparatus and an invoice 
routing method and apparatus. 

Background to the Invention 

A vast number of firms are involved in commerce which itself involves a massive 
traffic in invoices. Traditionally, invoices have been distributed largely by 
conventional mail. However, electronic communication of invoices has become 
more commonplace. 

Electronic distribution of invoices suffers from the problem of incompatibility 
between the accounting practices and systems of the many organisations which are 
involved in transactions either as vendors or purchasers. 

Summary of the Invention 

It is an object of the present invention to provide a routing system for invoices, or 
indeed other data, which overcomes the incompatibility problem described above or 
the like. 

According to the present invention, there is provided a communication routing 
apparatus comprising: - 

input transmission line means; 

output transmission line means; 

input processing means for processing signals received from the input 
transmission line means into an intermediate form having predetermined 
characteristics, the processing of each signal being dependent on its source; 

output processing means for processing signals in said intermediate form, 
produced by the input processing means, into signals in selected forms, the 
processing of each signal being dependent on its destination; and 

transmission means for transmitting signals, produced by the output 
processing means, via the output transmission line means to their destinations. 
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Thus, the parties to a communication need not themselves be able to convert signals 
between their respective formats. 

The input and output transmission line means may be implemented using the same 
physical electrical or optical conductors. The transmission line means preferably 
provide a connection to the Internet. 

Preferably, an apparatus according to the present invention includes means storing a 
plurality of input signal processing mapping definitions, wherein the input 
processing means is configured to select an input signal processing mapping 
definition in dependence on the source of the signal being processed and process 
said signal according to the selected input signal processing mapping definition to 
convert said signal into said intermediate form. 

Preferably, an apparatus according to the present invention includes means storing a 
plurality of output signal processing mapping definitions, wherein the output 
processing means is configured to select an output signal processing mapping 
definition in dependence on the destination of the signal being processed and 
process said signal according to the selected output signal processing mapping 
definition to convert said signal into the form required according to its destination. 

Preferably, an apparatus according to the present invention includes storage means 
for storing signals produced by the input processing means, wherein the output 
processing means reads signals in said intermediate form from the storage means 
before processing them. 

Preferably, an apparatus according to the present invention includes storage means 
for storing signals, received by the input processing means, so as to maintain a 
record of received signals. 

Preferably, the input processing means is adapted to determine the source of a 
received signal from a buffer location from which it is taken for processing and 



select the appropriate input mapping definition in dependence thereon. More 
preferably, the input processing means is adapted to produce a plurality of signals in 
said intermediate form from a received signal comprising one transmission session. 

Preferably, the output signal processing means is adapted to obtain a signal 
destination id from each intermediate form signal being processed and select the 
appropriate output mapping definition in dependence thereon. More preferably, the 
output signal processing means is configured to send its output signals to buffer 
means selected in dependence on the destinations thereof. 

Preferably, the input processing means is configured to apply the selected input 
mapping definitions to perform data format conversions on data represented by said 
received signals. More preferably, the input processing means is configured to add 
data to that represented by said received signals. 

Preferably, the output processing means is configured to apply the selected output 
mapping definitions to perform data format conversions on data represented by said 
intermediate form signals. 

Preferably, the input, intermediate form and output signals represent data files. 

The present invention also extends to a method and apparatus for routing invoices. 

An invoice routing apparatus according to the present invention comprises:- 
receiving means for receiving invoices; 

input processing means for processing received invoices into an intermediate 
form having predetermined characteristics, the processing of each invoice being 
dependent on the identity of the raiser of the invoice; 

output processing means for invoices in said intermediate form, produced by 
the input processing means, into invoices in selected forms, the processing of 
invoice in said intermediate form being dependent on the identity of the party being 
invoiced; and 
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transmission means for transmitting invoices, ptoduced by the output 
processing means to their destinations. 

An invoice routing method according to the present invention comprises:- 
5 receiving an invoice; 

electronically processing said received invoice into an intermediate form 
having predetermined characteristics in dependence on the identity of the raiser of 
the invoice; 

electronically processing said intermediate form invoice into an invoice in a 
10 form selected in dependence on the identity of the party being invoiced; and 
sending said invoice in said selected form to its destination. 

Brief Description of the Drawings 

Figure 1 is a generalised dataflow diagram of a system including a routing apparatus 
15 according to the present invention; 

Figure 2 is a generalised dataflow diagram of a further system including a routing 
apparatus according to the present invention; 

Figure 3 shows the elements of system employing an OSI layer 7 routing apparatus 
of the form illustrated in Figure 2; 
20 Figure 4 illustrates the configuration of the web server machine of Figure 3; 

Figure 5 is a flowchart illustrating a first method for the transfer of invoice data to 
the invoice routing system of Figure 3; 

Figure 6 shows the user interface of an applet used in the method illustrated in 
Figure 5; 

25 Figure 7 is a flowchart of a method of generating invoices using the invoice routing 
system of Figure 3; 

Figure 8 is a flowchart of an input signal conversion process; 
Figure 9 is a flowchart of an output signal conversion process; 
Figure 10 is a flowchart of a invoice file download process; and 
30 Figure 1 1 illustrates a mapping definition file used by the system shown in Figure 3. 

Detailed Description of the Preferred Embodiment 
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An embodiment of the present invention will now be described, by way of example, 
with reference to the accompanying drawings. 

Referring to Figure 1, first and second data transmission processes 1, 2 need to 
5 transmit data to first and second data receiving processes 3, 4. However, there is no 
agreement between these processes 1, 2, 3, 4 as to the data format that should be 
used for such transmissions. 



One solution would be for the first and second data transmission processes 1, 2 to 
10 convert the transmitted data into the form required by the destination data receiving 

process 3, 4. However, this requires the transmitting process 1, 2 to know the 
i-A current required data format of the destination data receiving process 3, 4. 

p Alternatively, the data format conversion could be carried out at the destination 

pjjj data receiving process 3, 4. However, this would require the data receiving 

r | 15 processes 3, 4 to have a set of data conversion routines for all of the data 
Sj transmission processes 1, 2 from which it might receive a signal. These 

s arrangements are undesirable because each new process 1, 2, 3, 4 which is added 

M 

ry potentially requires N new conversion routines, where N is the number of data 

transmission processes when a data receiving process is added and the number of 

Q 20 data receiving processes when a data transmission process is added. Furthermore, 
when the format used by a non-converting process is changed, this information 
must be propagated to all of the converting processes. 

The solution to this problem is the provision of an intelligent router 5. The 
25 intelligent router 5 performs both routing and signal format conversion. At most, 
the intelligent router 5 comprises an input signal conversion process 6, 7 for each 
data transmission process 1, 2, a routing implementation 8 and an output signal 
conversion process 9, 10 for each data receiving process 3, 4. 

30 Signals from the first data transmission process 1 are converted into a standard 
intermediate format by the respective input signal conversion process 6 and then 
routed to the appropriate output data conversion process 9, 10, for conversion from 
the standard intermediate format into the appropriate format for its destination, by 
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the routing implementation 8 according to its address. A signal from the second 
data transmission process 2 is similarly processed although it is converted into the 
standard intermediate format by the other input conversion process 7. 

5 In this case, it can be seen that each new data transmission process or data 
reception process can only require the addition on a maximum of one new 
conversion process. Furthermore, changes in formats used by data transmission 
processes and data receiving processes need only be notified to the intelligent router 
5. 

10 

It will be appreciated that the intelligent router 5 may be distributed, consisting of 
an internal network with conversion processes available at its boundaries. 
Furthermore, the routing implementation 8 may be provided by one or more 
dedicated processes or by aspects of the input and/or output conversion processes. 

15 

Referring to Figure 2, the input signal conversion processes 6, 7 of Figure 1 are 
replaced by a generic input signal conversion process 6a which processes incoming 
signals according to mapping definitions 6b selected on the basis of the source of 
the signal being converted. Similarly, the output signal conversion processes 9, 10 
20 of Figure 1 are replaced by a generic output signal conversion process 9a which 
processes signals according to mapping definitions 9b on the basis of the 
destination of the signal being converted. The generic output signal conversion 
process 9a also provides the routing implementation. 

25 The present invention may be implemented at various layers of the ISO networking 
reference model. An application layer, i.e. layer 7, embodiment for the transfer of 
invoice data, including credit note data and the like, will now be described by way of 
example. 

30 Referring to Figure3, the Internet 11 extends across a plurality of countries 12, 13 
(only two shown). An invoice routing system 14 is connected to the Internet 11. 
Additionally, first, second, third and fourth supplier computers 15, 16, 17, 18 
belonging to first, second, third and fourth suppliers respectively, first and second 
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buyer computers 19, 20 belonging to first and second buyers respectively, a head 
office computer 21 belonging to a holding company and a fiscal authority computer 
22 are connected to the Internet 1 1 . 

5 The first, second and third supplier computers 15, 16, 17 are conventional 
computers with access to invoice files (not shown) created by the respective 
supplier's accounting system (not shown). The fourth supplier computer 18 does 
not have access to invoice data files and invoices must be generated manually in co- 
operation with the invoice routing system 14. 

10 

The buyer computers 19, 20 are conventional computers which can generate files 
jM> that are accessible to the respective buyer's accounting systems (not shown). 

. . 

The head office computer 21 and the fiscal authority computer 22 are also 
f|j 15 conventional computers. 

s 

3 The first and third suppliers are subsidiaries of the holding company operating the 

as, head office computer 21. 

q 20 The first and third supplier computers 15, 17 provide invoice data in a first format. 

The same format is used because they belong to the same group of companies. The 
second supplier computer 16 provides invoice data in a second format. The first 
and second buyer computers 19, 20 require invoice data in third and fourth formats 
respectively. 

25 

The invoice routing system 14 comprises a web server machine 23, a data warehouse 
machine 24, an administration machine 25, an invoice processing machine 26, a 
printer 27, a security server machine 28, a first firewall 30 between the web server 
23 and the Internet 11, second firewall 31 between the web server machine 23 and 
30 the local area network. The local area network 29 provides for communication 
between the various machines 23, 24, 25, 26, 28 and the printer 27. 



- 8 - 



The data warehouse machine 24 provides a platform for a relational database 
management system (RDBMS) 24a. The relational database management system 24a 
contains tables storing: 

(a) system configuration data, such as country codes, valid options for date and 
5 currency formats and the details of mapping definitions; 

(b) client data, such as names, addresses, tax numbers, and data mapping 
definition ids; and 

(c) audit trail and transaction records. 

The supplier, buyer, head office and fiscal authority computers 15, 22 all interact 
with the invoice routing system 14 through the agency of the web server machine 23 
and do not need to have software other than a Java-enabled web browser in order to 
make use of the invoice routing system 14. 

Referring to Figure 4, the web server machine 23 supports a web server 40 enabled 
for secure communication, e.g. using SSL (secure sockets layer), a plurality of CGI 
scripts 41, a file reception process 42 and a file transmission process 43. 

G The transfer of invoice data from the first supplier computer 15 to the invoice 

20 routing system 14 will now be described. 

Referring to Figure 5, in order to upload invoice data to the invoice routing system 
14, the operator of the first supplier computer 15 uses a web browser to "log in" to 
the web server 40 and establish a secure communication path (step si). Having 

25 logged in, the operator can follow a hypertext link to an invoice file upload page 

(step s2). The file upload page includes a Java applet. The Java applet is signed so 
that it has access to the file system of the first supplier computer 15. As shown in 
Figure 6, the applet's user interface includes a list box 50 for listing the files to be 
uploaded, a button 51 for opening a file selection dialog so that the operator can 

30 specify the invoice files to be uploaded and a button 52 for starting the file transfer. 

When the user has specified the files to be uploaded (step s3) and starts the file 
transfer (step s4), the applet establishes connection to the file reception process 42 
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at the web server machine 14 (step s5) and transmits the entered file count and the 
specified files to the file reception process 42 (step s6). If the upload is successful 
(step s7), the file reception process 42 validates the digital certificate sent with the 
file through a dialogue with the security server machine 28 (step s8). If the 
■ 5 certificate is not valid the file reception process 42 logs an error (step s9) otherwise 
it sends a copy of the received file or files to the data warehouse machine 24 (step 
slO) where they are stored temporarily, e.g. for 5 days, so that the files do not need 
to be uploaded again if the conversion process fails. The file of received invoice 
data is then sent to a directory, associated with the uploading party and which is 
10 accessible to the invoice processing machine 26 (step sll). The operator is then 

informed of the success of the upload (step sl2). The operator is also informed of 
y> upload failures (step si 3). 

C3 

'¥,0 The uploading of invoice data files from the second supplier computer 16 is 

§1 

?y 15 performed in the same way. 

i The third supplier computer 17 uses an automatic upload process. This process is 

m i triggered by scheduling software on the third supplier computer 17 and is effected 

£3 by a Java application which performs FTP over an HTTP link to the web server 

jpg 20 machine 23 and prohibits operator intervention. The use of FTP over an HTTP 
link avoids the need for a direct FTP link between the third supplier computer 17 
and the invoice routing system 14. The use of this, and the prohibition of operator 
intervention increases system security. 

25 The fourth supplier computer 18 does not have access to invoice data files suitable 
for uploading, for instance the owner uses manual accounts. Referring to Figure 7, 
in this case, the operator of the fourth computer 18 logs into the web server 40 
(step si 01) and follows a link to a set of invoice generation html forms, which 
provide inputs for CGI scripts 41. The set of forms enables the operator of the 

30 fourth supplier computer 18 to enter invoice details (step si 02) and upload them to 
the web server machine 23 (step si 03). The forms are generated using data in the 
data warehouse machine 24 so that, for instance, entry of a buyer id causes name 
and address data for the buyer to be filled in. 
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The operator uses the invoice generation forms to enter one or more invoices (steps 
s!02 and sl04). When each invoice has been entered, its data is submitted to a CGI 
script 41 at the web server machine 23. When there are no more invoices to upload 
(step si 05), the operator is presented with a summary of the uploaded invoices and 
given the option of saving or saving and printing the invoices (step sl06). An FTP 
connection is then established (step si 07), using a signed applet received from web 
server machine 23, and the invoices are downloaded and stored (step si 08) and 
optionally printed (step si 09). The uploaded invoices are processed as in the case 
of the first supplier computer's uploading of invoice data, starting at step s7 of 
Figure 5. 

The invoice processing machine 24 implements the signal conversion processes 6a, 
9a (Figure 2), with the routing implementation 8 (Figure 1) being provided by the 
output signal conversion process 9a. 

The input signal conversion process 6a processes invoice data from the file 
reception process 42 as follows. Referring to Figure 8, the invoice files in the 
directory associated with a supplier are concatenated (step s200) and the identity of 
the directory, in which the invoice data is stored, is then used to select the 
appropriate mapping definition 6b from a database of mapping definitions at the 
data warehouse machine 24 (step s201). Thus, a first mapping definition is selected 
for invoices from the first and third supplier computers 15, 17, a second mapping 
definition is selected for invoices from the second supplier computer 1 6 and the 
third mapping definition is selected for invoices from the fourth supplier computer 
18. Using information from the selected mapping definition, the invoice data file 
being processed is split into its constituent invoices (step s202). 

Each invoice is then converted by the input signal conversion process into a 
standard intermediate format according to the selected mapping definition. This 
conversion process includes preprocessing them to separate their individual fields 
and copying them to the corresponding fields of the intermediate format as 
necessary (step s203), the addition of static data, e.g. the name and address of the 
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source of the invoice (step s204), and system dynamic data including a transaction 
code, a transaction id and the mapping definition used (step s205). The converted 
invoice data is then validated (step s206). If the converted data is invalid, the 
source of the invoice is notified of the error by email (step s207) and the error is 
logged (step s208). 

If the converted data is valid, its details are stored by the relational database 
management system 24a at the data warehouse machine 24, so that they are available 
for queries from the suppliers, buyers, head offices and fiscal authorities concerned, 
(step s209) and the standard intermediate format data is made available to the 
output signal conversion process (step s210). 

Following steps s208 and s210, it is determined whether all of the invoices in the 
concantenated file have been processed (step s211) and when all of the invoices 
have been processed, an html summary is sent by email to the supplier concerned 
(step s212). 

Referring to Figure 9, for each standard intermediate format invoice to be 
processed, the output signal conversion process 9a determines which mapping 
definition is required based on the buyer, to which the invoice is addressed (taken 
from a predetermined field of the standard intermediate format), and retrieves it 
from a database of mapping definitions 9b at the data warehouse machine 24 (step 
s401). It then adds a supplier abas, if required by the buyer according to the 
mapping definition (step s402). The supplier alias is a code for the supplier 
provided by the buyer to which the invoice is addressed. A copy of the 
unconverted invoice data is then saved at the data warehouse machine 24 where it 
will be maintained for a predetermined period in case a problem with the output 
conversion occurs (step s403). After the invoice copy has been saved, the output 
signal conversion process converts the invoice from the standard intermediate 
format into that required by the buyer to which it is addressed. This includes 
converting the contents of individual fields and reordering them as necessary (step 
s404) and the addition of static and derived data, e.g. amounts in alternate 
currencies, required by the buyer (step s405). 
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If the converted invoice fails to meet criteria specified by the buyer (step s406), an 
email notification is sent to the supplier who issued the invoice (step s407) and the 
error is logged (step s408). If the converted invoice is rejected because it is on the 
5 buyer's blocking list (step s409), email notifications are sent to both the supplier 
and the buyer (step s410) and the event is logged (step s411). Finally, if the 
converted invoice is acceptable, it is stored in a directory assigned to the buyer (step 
s412). This directory is accessible to the file transmission process 43 at the web 
server machine 23. 

10 

The blocking list is a list of suppliers from which the buyer will not accept invoices. 
An allow list is alternatively provided to specify the suppliers from whom a buyer 
will accept invoices. 

15 Referring to Figure 10, in order to download invoices addressed to the first buyer, 
the operator of the first buyer computer 19 logs into the web server 40 (step s501) 
and follows a link to a download page (step s502). The download page includes a 
signed applet which allows the operator to identify a destination directory for the 
downloaded invoices and a download initiating button. When the operator has 

20 specified a destination directory (step s503) and clicked on the button, the applet 
retrieves the buyer's invoices from the directory where they were stored by the 
output signal conversion process (step s504). When the file transfer is complete the 
operator is notified by the applet (step s505). Additionally, the file transmission 
process sends an email containing a summary of the downloaded files to the buyer 

25 (step s506). 

The second buyer computer 20 uses an automatic download process. This process 
is triggered by scheduling software on the second buyer computer 20 and is effected 
by a Java application which performs FTP over an HTTP link to the web server 
30 machine 23 and prohibits operator intervention. The use of FTP over an HTTP 
link avoids the need for a direct FTP link between the second buyer computer 16 
and the invoice routing system 14. The use of this, and the prohibition of operator 
intervention, increase system security. 
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Following the successful download of an invoice file, individual invoices are also 
sent to the respective buyer via e-mail in HTML format. These invoice copies may 
include data, such as VAT registration numbers, that is not included the 
downloaded invoice file but which is required on printed invoices, which themselves 
may be a legal requirement. 

The e-mails are received by the buyer's e-mail client (not shown) from where they 
can be stored, printed and/ or distributed. 

The supplier, buyer, head office and fiscal authority computers 15, ...,22 can be 
used to query data in the data warehouse machine 24 within secure HTTP sessions. 
The data that can be returned to the querying party depend on its legitimate area of 
interest. Thus, suppliers can access records of the invoices which they have 
generated, buyers can access records of the invoices addressed to them, 
parent/holding companies can access records of invoices generated by or addressed 
to their various subsidiaries and fiscal authorities can access records of invoices 
relating to transactions over which they have jurisdiction. The suppliers and: buyers, 
head office and fiscal authorities can also obtain HTML format invoices which can 
be printed out locally to provide a hard copy from the data warehouse machine 24. 

Additionally, the operator of the invoice routing apparatus 14 can use the records of 
the invoices passing through the system to calculate charges to suppliers and buyers 
using the system. 

The mapping definitions, referred to above, comprises sets of rules that map fields 
of invoice data files in one form onto corresponding fields of another form. The 
mapping definitions also define any data representation format conversions, e.g. 
yymmdd to ddmmyy for dates, and any additional static or derived data that needs 
to be added. The mapping definitions may also include rules for validating the 
result of the conversion process controlled thereby. 
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In the present example, the intermediate format is implemented using a plurality of 
tables of a relational database managed by the relational database management 
system 24a. The fields of the intermediate format stored in respective tables of the 
database. Thus, all supplier city address fields are stored in a supplier city address 
5 table and each invoice bought/ ordered item line is stored in an item line table. 

The contents of a mapping definition file 6b for converting input invoice data into 
the intermediate format illustrated above is shown in Figure 1 1 (the column headers 
are shown in the interest of clarity and are not included in the file represented). 

10 

Referring to Figure 11, the mapping definition file 6b has a row for each label used 
in converting to the intermediate format. Each row comprises the label name, flags 
to indicate whether it is a container, i.e. contains other labels, and whether it has a 
data element, the name of any attribute used in the data field, minimum and 
15 maximum values for the occurrence of the data labelled by the label, the format of 
any data element, e.g. text or number, the size of the element and the data source 
for each occurrence of the data element. 

The preprocessing, referred to above, uses knowledge about the field separators 
20 and/ or field headers used in incoming invoice files so that the incoming invoice 

fields are separated in a consistent manner. However, at this stage no judgement as 
to the meaning of the fields is made. 

The input signal conversion process 6a opens the mapping definition file 6b and 
25 first reads an Invoice label. No data is associated with this label but it is provided 
for possible future use. However, it is a container. Next an InvoiceHeader label is 
found. This label is a container and does not contain data. Next the process 6a an 
InvoiceType label. However, the mapping definition file 6b specifies that this tag 
has an attribute "type" and that the data for this attribute is "invoice" if fieldA form 
30 the pre-processed input file is "I" and otherwise "credit note". Consequently, the 
process inserts a row comprising the invoice's unique id and "invoice" or "credit 
note" into the invoice type table of the intermediate form database. 



- 15 - 

The next invoice header item is the invoice number and accordingly the process 6a 
inserts a row comprising the invoice's unique id, and the invoice number from 
fieldC into the invoice number table of the database. 

5 The mapping definition file 6a specifies that there are two parties. Consequently, it 
inserts two rows into the party table of the database. The first row includes the 
invoice's unique id, a who field set to "supplier", the supplier's id from the system's 
client database, a link to a name record in a name database and a link to an address 
record in an address database. These name and address records are created using 

10 data from the system's client database. 

The second row includes the invoice's unique id, a who field set to "buyer", the 
buyer's id from the fieldB of the input file, a link to a name record in a name 
database and a link to an address record in an address database. These name record 
is set to null in the name table and address record is created using data from fieldE, 
fieldF, fieldG and fieldH of the pre-processed input file. 

There are also two Ref entries which cause reference records to be stored in a 
reference table. The records comprise the invoices unique id and a field comprising 
"QN" and "OT" respectively combined with data from the pre-processed input file. 

An invoice details section, opened with an InvoiceDetails label, follows the invoice 
header section and it can be seen that this comprises a separate section for each line 
of the items ordered/bought and a total section. Some of these elements are 
25 numbers and the element size column specifies the formats for them with the 

number of digits available before and after a decimal point. The values for each line 
are taken from a field from the pre-processed file which is an array of elements that 
can be selected using the field name (fieldP) and an index. In the example shown, 
the index is calculated from the line number (L) where the first line is line 1. Each 
30 line is stored as a respective record in a line items table of the database. 

Since the intermediate format uses a database, conventional data merging 
techniques, such as mail merging, with mapping definitions in the form of templates 
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can be used to convert the intermediate format data into files having formats 
appropriate for their destinations. 

It can also be seen that the mapping definitions 6a include information regarding 
the form and repetition of fields for controlling the conversion process. 

In other embodiments, the invoices are uploaded and/ or downloaded using virtual 
private network (VPN) connections to the invoice routing system 14. 

It will be appreciated that many modifications can be made to the embodiment 
described above. In particular, the allocation of processing tasks to particular 
machines may be changed. At one extreme all of the functions of the invoice 
routing system 14 could be performed using one computer. At another extreme 
each process may be performed in parallel on many machines with clustering of 
servers for the data warehouse. Furthermore,, one or more of the personal 
computers could be replaced by mini-computers or mainframes. It is the ability of 
these computers to communicate with each other that is important rather that the 
particular types of computers used. 



